1. Field of the Invention
This invention relates generally to the field of configuration of computer systems, and specifically to the automatic generation of Advanced Configuration and Power Management Interface ("ACPI") Source Language ("ASL") code for the peripheral resource configuration of a computer having an ACPI enabled operating system("OS").
2. Description of the Related Art
ACPI is a specification jointly developed and released to the public by Microsoft, Intel, and Toshiba. It defines an extensible means by which an OS can be given greater control over the power management and resource management in computer systems, such as PCs. ACPI defines a hardware and software interface by which an OS can manipulate the characteristics of motherboard devices. This technology differs from existing Basic Input/Output System ("BIOS") technologies in at least two regards: (i) the BIOS support code is written in a p-code called ACPI Machine Language ("AML"), discussed further herein, rather than in the native assembly language of a platform; and (ii) the BIOS support code does not determine the policies or time-outs for power or resource management. Rather, these policies are determined by the operating system.
The ACPI hardware interface provides functionality to the OS in two categories (i) control/detection of system control events using a normal interrupt called System Control Interrupt ("SCI"), rather than a System Management Interrupt ("SMI"), and (ii) control of the system power state. The details of a platform's support for the hardware interface are provided in a set of well-defined tables within the system BIOS.
The ACPI software interface provides the means for the OS to find the different ACPI related tables in the system BIOS and means for the OS to understand and control the characteristics of the motherboard devices using AML. The AML resides in the tables within the system BIOS.
ACPI Source Language ("ASL") provides the mechanism by which the OS controls power management, Plug-n-Play and docking support under the latest releases of, for example, the Windows and Windows NT operating systems that are required to be ACPI compliant. The ASL is compiled during the BIOS build process into AML.
ASL is the preferred source language for writing ACPI control methods. Most OEMs and BIOS developers write control methods in ASL. The ASL code is then translated by a translation tool to AML code versions of the control methods. It should be noted that ASL and AML are different languages although they are closely related.
Every ACPI compliant OS must support AML. However, use of ASL is not mandatory even though it is highly desirable to use ASL. At least in theory, a user can develop their own arbitrary source language, and use a translator to translate this arbitrary source language into AML.
AML is the ACPI control method virtual machine language, i.e., a machine code for a virtual machine which is supported by an ACPI-compatible OS. It is a pseudo-code assembly language that is interpreted by an OS driver. ACPI control methods can be written in AML, but programmers ordinarily code the control methods in ASL. Chapter 15 of the ACPI Specification, Revision 1.0a, published Jul. 1, 1998, by Intel, Microsoft, and Toshiba, describes the ASL reference, the disclosure of which is incorporated herein in its entirety. The ACPI Specification, Revision 1.0a, will hereafter be referred to as the "ACPI Specification."
AML is the language processed by the ACPI method interpreter. It is primarily a declarative language and provides a set of declarations that is compiled by the ACPI interpreter into the ACPI name space at definition block load time. One of the requirements of AML is that its access to memory, I/O, and PCI configuration space are either static or else the capabilities provided for dynamic values are so limited as to be largely useless because they are:
(a) evaluated at the time when the AML is first loaded by the OS; and PA1 (b) are very difficult to modify at that point. PA1 1. The OS no longer calls the PnP run-time services. PA1 2. The ASL code (which replaces the PnP run-time calls) cannot access the CMOS memory to determine the user settings. PA1 3. The OS assumes that if the _DIS (Disable) method exists for a device, calling it will disable the device. However, this can conflict with a user setting that specifies the device as being secured, and hence not changeable by the OS in this manner. PA1 4. The OS assumes that if the _PRS (Possible Resource Settings) object is found under a device, then the device must support multiple configurations even if the user's setting indicates otherwise. Therefore, the OS can modify the resource settings in a manner inconsistent with a user's indicated preference using the Setup program. PA1 (i) ACPI Tables 30--These tables describe the interfaces to the hardware. These interfaces can take a variety of configurations and include the descriptions in AML code. Some of the descriptions limit what can be built although most descriptions allow the hardware to be built in arbitrary ways, and can also describe arbitrary operation sequences needed to make the hardware function. Since, the ACPI tables can make use of AML which is interpreted, the OS contains an AML interpreter 11 that executes procedures encoded in AML and stored in the ACPI tables 30. PA1 (ii) ACPI Registers 10--These are a limited part of the hardware interface, and are described, at least in location, by the ACPI tables 30. PA1 (iii) ACPI BIOS 20--refers to the part of the firmware that is compatible with the ACPI specifications. Note that the ACPI BIOS 20 is normally not separate from a system BIOS 21 but is shown as a separate component to emphasize its additional functionality and compatibility with the ACPI specifications. Therefore, this ACPI BIOS 20 includes code that boots the machine, as well as implementing interfaces for sleep, wake, and some restart operations.
For example, there are at least two objects where the ability to modify the object's parameters are desirable: Processor and OperationRegion. In general, OperationRegion(name, type, offset, length) provides the ASL code access to a chunk of memory, I/O space, PCI configuration space, embedded controller space, or SMBus space. However, although "offset" and "length" are expressions, they are only evaluated at the time when the OS loads the ACPI tables and is, therefore, difficult to modify based on changed conditions in the system, such as, when the I/O addresses are relocated by the Motherboard Configurable Devices/Plug and Play routines("MCD/PnP") or the jumper settings on the motherboard.
The ACPI Processor(name, APICID, offset, length) object declares a CPU and its power management control I/O ports to the OS. The "offset" and "length" are not expressions and, therefore, must be located at build time. This is extremely limiting, especially, if it is desired to relocate these I/O addresses using, for example, MCD/PnP.
It should be noted that Plug and Play (PnP) is the name of a technology developed by, inter alia, Microsoft and Intel, that lets PC hardware work automatically with attached peripheral devices. Motherboard Configurable Devices (MCD) is Phoenix Technologies' implementation of the PnP specification for use in a BIOS. Plug and Play technology is implemented in hardware, operating systems and in supporting software such as device drivers and BIOS. There are a variety of Plug and Play technologies, including, for example, BIOS, ISA, SCSI, IDE CD-ROM and some others. In this specification, reference to Plug and Play will be to the Plug and Play BIOS specification and to the MCD implementation of the Plug and Play BIOS specification.
Another problem arises because, in a system BIOS, users can enter the Setup program to modify the settings of motherboard integrated peripherals. The settings often include, for example, the device's default resource settings (I/O, IRQ, etc.), whether the device is enabled or disabled, and whether the OS is allowed to modify the device's settings at run-time.
In a legacy resource management system, such as PnP, these settings control the information that the run-time services return to the OS. Under ACPI, however, there are certain new problems that make this type of integration more difficult.
The following subsection provides an overview of the ACPI architecture that facilitates a better understanding of the present invention which is summarized in the following section titled "Summary of the Invention."